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ABSTRACT 


Concurrent  Euclid  (Euclid-C)  is  a  programming  language 
designed  for  implementing  system  software.  It  consists  of  a  sub¬ 
set  of  the  Euclid  programming  language  [1]  called  Euclid-S  plus 
concurrency  features  based  on  monitors  [2]. 

This  paper  defines  Concurrent  Euclid  independently  of  Euclid. 
It  begins  with  a  definition  of  Euclid-S  and  then  describes  the 
concurrency  features  to  give  Euclid-C.  An  understanding  of  the 
basic  concepts  of  the  Pascal  family  of  programming  languages  is 
assumed  . 


Copyright  (C)  1980  by  the  University  of  Toronto. 
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INTRODUCTION 


This  paper  defines  a 
[1]  called  Euclid-S  and 
monitors 
form  a 
Eucl id-C 
so  ft ware 


based  on 
combine  to 
Eucl id-C . 
ing  system 
systems  and 


compi 1 ers . 


subset  of  the  Euclid  programming  language 
a  set  of  concurrency  extensions  to  Euclid 
[2].  Euclid-S  plus  the  concurrency  features 
new  language  called  Concurrent  Euclid  or 
has  been  designed  specifically  for  implement- 
and  in  particular  for  implementing  operating 


The  first  part  of  this  document  defines  of  the  Euclid-S  subset 
independently  of  Euclid.  The  second  section  describes  the  con¬ 
currency  features  added  to  form  Euclid-C.  The  last  section 
describes  extensions  to  Euclid-C  designed  to  allow  separate  com¬ 
pilation  of  procedures,  functions,  modules  and  monitors. 
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I.  THE  EUCLID-S  SUBSET 


This  section  describes  the  Euclid-S  subset  of  Euclid. 
Euclid-S  is  defined  independently  of  Euclid  and  no  previous 
knowledge  of  the  Euclid  programming  language  is  required.  An 
understanding  of  the  basic  concepts  of  the  Pascal  family  of  pro¬ 
gramming  languages  is  assumed. 


IDENTIFIERS  AND  LITERALS 
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1. 

A  string  literal  is  any  sequence  of  characters  not  including  a 
single  quote  (')  surrounded  by  quotes.  Within  strings,  the  char¬ 
acters  quote,  dollar  sign,  new  line  and  end  of  file  are 
represented  as  $',  $$,  $N  and  $E  respectively.  As  well,  $T,  $S 
and  $ F  may  be  used  for  tab,  space,  and  form  feed  respectively. 

A  character  literal  is  a  dollar  sign  ($)  followed  by  any  sin¬ 
gle  character.  The  Euclid-S  character  literals  corresponding  to 
quote,  dollar  sign,  space,  tab,  form  feed,  new  line  and  end  of 
file  are  $$ * ,  $$$,  $$S,  $$T,  $$F,  $$N  and  $$E  respectively. 

A  integ er  literal  is  a  decimal  number,  an  octal  number  or  a 
hexadecimal  number.  A  decimal  number  is  any  sequence  of  decimal 
digits.  An  octal  number  is  any  sequence  of  octal  digits  followed 
by  #8.  A  hexadecimal  number  is  any  sequence  of  hexadecimal  di¬ 
gits  (represented  as  the  decimal  digits  plus  the  capital  letters 
A  through  F)  beginning  with  a  decimal  digit  and  followed  by  #16. 


SOURCE  PROGRAM  FORMAT 

A  comment  is  any  sequence  of  characters  not  including  comment 
brackets  surrounded  by  the  comment  brackets  {  and  } .  Comments 
may  cross  line  boundaries. 

A  sepa rator  is  a  comment,  blank,  tab,  form  feed  or  source  line 
boundary.  Euclid-S  programs  are  free-format;  that  is,  the  iden¬ 
tifiers,  keywords,  literals,  operators  and  special  characters 
which  make  up  a  program  may  have  any  number  of  separators  between 
them.  Separators  cannot  be  embedded  in  identifiers,  keywords, 
literals  or  operators,  except  that  blanks  may  appear  as  part  of 
the  value  of  a  string  literal.  Identifiers,  keywords  and 
literals  must  not  cross  line  boundaries.  At  least  one  separator 
must  appear  between  adjacent  identifiers,  keywords  and  literals. 
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NOTATION 


The  following  sections  define  the  syntax  of  Euclid-S. 

The  following  notation  is  used: 

{item}  means  zero  or  more  of  the  item 
[item]  means  the  item  is  optional 

Keywords  are  given  in  lower  case.  Special  symbols  are  enclosed 
in  double  quotes  (")  . 

The  following  abbreviations  are  used: 
id  for  identifier 
expn  for  expression 
typeDefn  for  typeDef ini t ion 

In  both  Euclid-S  and  Euclid-C,  all  specified  semicolons  are 
optional.  Whenever  ";"  appears,  it  can  be  omitted. 


PROGRAMS 

A  main  program  consists  of  a  module  declaration. 

A  prog  ram  is  : 

moduleDeclaration  ";" 

Execution  of  a  program  consists  of  initializing  the  main  module, 
see  "Modules". 

Modules,  procedures  and  functions  can  be  compiled  separately; 
see  "Separate  Compilation". 


MODULES 


A  moduleDeclaration  is : 

var  id  ":" 
mod  ul e 

[imports  "("  [var]  id  {","  [var]  id}  ")  "  ";  "] 
[exports  "("  id  {","  id}  ")  "  ";  "] 

[  [not]  checked  "  ;  "] 

{declarationlnModule  "  ;  " } 

[initially 

proced ur eBody  ";"] 
end  module 

Execution  of  a  module  declaration  consists  of  executing  the 
declarations  in  the  module  and  then  calling  the  "initially"  pro¬ 
cedure  of  the  module.  Execution  of  a  Euclid-S  program  consists 
of  executing  the  main  module  declaration  in  this  way. 

Module  declarations  may  be  nested  inside  other  modules  but 
must  not  be  nested  inside  procedures  and  functions. 
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A  module  defines  a  package  of  variables,  constants,  types, 
procedures  and  functions.  The  interface  of  the  module  to  the 
rest  of  the  program  is  defined  by  its  imports  and  exports 
clauses . 

The  imports  clause  lists  the  global  identifiers  which  are  to 
be  visible  inside  the  module.  Variable  identifiers  may  be  im¬ 
ported  "var"  (or  not).  Only  those  variable  identifiers  which  are 
imported  "var"  may  be  assigned  to  or  passed  to  var  parameters 
within  the  module.  Imported  module  and  collection  identifiers 
must  be  imported  using  "var".  Imported  identifiers  must  not  be 
redeclared  inside  the  module. 

The  exports  clause  lists  those  identifiers  defined  inside  the 
module  which  may  be  accessed  outside  the  module  using  the  "." 
operator.  Exported  variables  cannot  be  assigned  to  or  passed  as 
var  parameters.  Unexported  identifiers  cannot  be  referenced  out¬ 
side  the  module. 

Named  types  declared  inside  a  module  are  opaque  outside  the 
module,  that  is,  they  are  not  considered  equivalent  to  any  other 
type.  Exported  variables  and  constants  whose  type  is  opaque  can¬ 
not  be  subscripted,  field  selected  or  compared  for  other  than 
equal ity . 

Modules  may  be  "checked";  this  causes  all  assert  statements, 
subscripts  and  case  statements  in  the  module  to  be  checked  for 
validity  at  run-time.  In  addition,  a  particular  implementation 
may  check  other  conditions  such  as  ranges  in  assignments. 
Modules  not  already  nested  inside  an  unchecked  module  are  checked 
by  default  and  must  be  explicitly  declared  using  "not  checked"  to 
turn  off  run-time  checking. 

Even  though  declared  like  variables,  modules  are  not  variables 
and  cannot  be  assigned,  compared,  passed  as  parameters  or  export¬ 
ed.  Module  identifiers  must  be  imported  using  "var". 

Modules  can  be  separately  compiled  if  desired;  see  "Separate 
Compilation" . 


DECLARATIONS 

A  d eel ar a tionln Module  is  one  of  the  following: 

a.  constantDeclar at  ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBind ing 

e.  moduleDeclarat ion 

f.  collec tionDeclarat ion 

g.  proced ureDeclar at  ion 

h.  func tionDeclarat ion 

i.  conver terDeclarat ion 

j.  assert  ["("  expn  ")"] 
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Forms  (a)  through  (i)  are  declarations  for  new  identifiers  as 
explained  in  the  following  sections.  Form  (j)  is  an  assert 
statement;  see  "Statements".  An  identifier  must  be  declared  tex- 
tually  preceding  any  references  to  it. 


CONSTANT  DECLARATIONS 
A  constantDeclarat ion  is  one  of: 

a.  [pervasive]  const  id  expn 

b.  [pervasive]  const  id  typeDefn  "  :  =  " 

"("  manifestExpn  { " , "  mani festExpn}  ") " 

A  constantDeclarat ion  gives  a  name  to  a  value  which  is  con¬ 
stant  throughout  the  scope  of  the  declaration.  The  value  of  a 
scalar  constant  can  be  manifest  or  nonmani fest .  A  manifest  con¬ 
stant  or  expression  is  one  whose  value  is  known  at  compile- time. 
A  nonmanifest  constant  or  expression  must  be  evaluated  at  run¬ 
time  . 

Form  (a)  names  a  scalar  constant  or  string  literal.  The  type 
of  the  constant  is  the  type  of  the  value  expression.  The  value 
of  the  scalar  expression  may  be  manifest  or  nonmanifest. 

Form  (b)  declares  an  array  constant.  The  typeDefn  must  be  an 
array  type  or  named  array  type  whose  component  type  is  scalar. 
The  list  of  expressions  gives  the  values  of  the  elements  of  the 
array  constant.  The  element  values  must  be  manifest  expressions 
assignable  to  the  element  type  of  the  array.  The  number  of  ele¬ 
ment  values  specified  must  be  exactly  the  number  of  elements  in 
the  array. 

Constants  declared  using  "pervasive"  are  automatically  import¬ 
ed  into  all  subscopes  of  the  scope  in  which  they  are  declared. 
Such  constants  need  not  be  explicitly  imported. 


VARIABLE  DECLARATIONS 
A  var iableDeclarat ion  is : 

[register]  var  id  ["("  at  manifestExpn  ")"]  typeDefn 
[":  =  "  expn] 

A  var iableDeclarat ion  declares  a  variable  of  the  specified 
type.  The  "at"  clause  declares  a  variable  at  an  absolute  machine 
location.  Variables  may  optionally  be  declared  with  an  initial 
value  which  is  assigned  to  the  variable  when  the  declaration  is 
executed.  Fields  of  records  cannot  have  initial  values  or  "at" 
clauses . 

Local  variables  in  procedures  and  functions  may  optionally  be 
declared  "register".  This  is  a  hint  to  the  compiler  that  it 
should  attempt  to  allocate  the  variable  to  a  register.  Register 
variables  cannot  be  bound  to  nor  passed  to  a  reference  parameter. 
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TYPES  AND  TYPE  DECLARATIONS 


A  t ype Declaration  is : 


[pervasive] 


type  id  "  =  "  typeBody 


The  typeBody  is  one  of: 

a  .  typeDe fn 
b.  forward 


A  typeDeclarat ion  gives  a  name  to  a  type.  The  type  name  can 
subsequently  be  used  in  place  of  the  full  type  definition.  A 
named  type  is  equivalent  to  the  type  that  it  names. 

Named  types  may  optionally  be  declared  "pervasive".  Type 
names  declared  using  "pervasive"  are  automatically  imported  into 
all  subscopes  of  the  scope  in  which  they  are  declared.  Such 
types  need  not  be  explicitly  imported. 


Form  ( b)  declares  a  forward  type, 
type  name  whose  definition  will  be  g 
tion  in  the  scope.  A  forward  type  c 
ment  type  of  a  collection  until 
given.  This  allows  the  declaration 
contain  pointers  to  other  elements  i 


A  forward  type  declares  a 
iven  in  a  later  type  declara- 
an  be  used  only  as  the  ele- 
its  real  type  definition  is 
of  collections  whose  elements 
n  the  collection. 


A  typeDe  fn 


is  one  of  the  following: 


a.  standardType 

b.  mani festConstant  manifestExpn 

c.  [packed]  array  indexType  of  typeDefn 

d.  set  of  baseType 

e.  [packed]  recordType 

f.  pointerType 

g .  namedType 
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imported  . 

Form  (b)  is  a  subrange  type.  The  leading  constant  must  be  a 
literal  or  manifest  named  constant  and  gives  the  lower  bound  of 
the  range  of  values  for  variables  declared  using  the  type.  The 
expression,  which  must  be  manifest,  gives  the  upper  bound  of  the 
range.  The  bounds  must  be  both  integer  values  or  both  character 
values.  The  lower  bound  must  be  less  than  or  equal  to  the  upper 
bound . 

A  scalar  type  is  a  subrange,  pointer  or  one  of  the  standard 
types. 

Form  (c)  is  an  array  type.  The  indexType  must  be  a  subrange 
type.  Char  or  a  named  type  which  is  an  indexType.  The  indexType 
gives  the  range  of  subscripts.  The  typeDefn  gives  the  type  of 
the  elements  of  the  array. 

Elements  of  an  array  variable  are  referenced  using  subscripts 
(see  "Variables  and  Constants")  and  themselves  used  as  variables. 
Array  variables  and  constants  may  also  be  assigned  (but  not  com¬ 
pared)  as  a  whole. 

Arrays  can  be  "packed",  which  allows  the  compiler  to  pack  the 
elements  more  efficiently  if  possible.  The  type  of  string 
literals  in  Euclid-S  is  "packed  array  l..n  of  Char"  where  n  is 
the  length  of  the  string. 

Form  (d)  is  a  set  type.  The  baseType  of  the  set  must  be  a 
subrange  of  integer  with  lower  bound  0  or  a  namedType  which  is  a 
baseType.  An  implementation  may  limit  the  upper  bound  of  a  set 
type  to  insure  efficient  code;  a  typical  limit  could  be  15. 

A  recordType  is : 

record 

{var  id  typeDefn 

end  record 

Variables  declared  using  a  record  type  have  the  fields  given 
by  the  variable  declarations  in  the  recordType.  Fields  of  a 
record  variable  may  be  referenced  using  the  "."  operator  (see 
"Variables  and  Constants")  and  themselves  used  as  variables. 
Record  variables  may  be  assigned  (but  not  compared)  as  a  whole. 

The  var iableDeclarations  in  a  record  type  must  not  have  ini¬ 
tial  values  and  cannot  be  declared  to  be  at  absolute  locations. 

A  po interType  is : 

"~"  collectionld 

Variables  declared  using  a  pointerType  are  pointers  to  dynami¬ 
cally  allocated  and  freed  elements  of  the  specified  collection 
(see  "Collections").  Pointer  variables  are  used  as  subscripts  of 
the  specified  collection  to  select  the  element  to  which  they 
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point.  The  selected  element  can  be  used  as  a  variable.  Pointer 
variables  may  be  assigned,  compared  for  equality  and  passed  as 
parameters . 

A  named Type  is : 

[moduleld  "."]  typeld 

The  typeld  must  be  a  previously  declared  type  name.  Type 
names  exported  from  a  module  are  referenced  outside  the  module 
using  the  "."  operator. 


TYPE  EQUIVALENCE  AND  ASSIGNABILITY 


Two  types  are  defined  to  be  equivalent  if  they  are 

(a)  subranges  with  equal  first  and  last  values 

( b)  arrays  (both  packed  or  both  unpacked)  with 
equivalent  index  types  and  equivalent  component 
types 


(c)  sets  with  equivalent  base  types 

(d)  pointers  to  the  same  collection 

A  declared  type  identifier  is  equivalent  to  the  type  it  names, 
with  the  following  exception.  When  an  exported  type  identifier 
is  used  outside  its  module,  as  "moduleld .typeld" ,  it  is  a  unique 
type,  equivalent  to  no  other  type. 


Each  type  definition  for  a  record  type  creates  a  new  type  that 
is  not  equivalent  to  any  other  record  type  definition. 


An  array  value  can  be  assigned  to  an  array  variable,  a  record 
value  assigned  to  a  record  variable,  a  set  value  assigned  to  a 
set  variable  and  a  pointer  value  assigned  to  a  pointer  variable 
only  if  the  source  and  target  of  the  assignment  have  equivalent 
types . 

An  expression  can  be  assigned  to  a  scalar  variable  only  if  (i) 
the  "root"  type  of  the  expression  and  the  "root"  type  of  the 
variable  are  equivalent,  and  (ii)  the  value  of  the  expression  is 
in  the  range  of  the  variable's  type.  The  "root"  type  of  Char  and 
character  subrange  types  is  Char.  The  root  type  of  Signedlnt, 
Unsignedlnt,  AddressType  and  integer  subranges  is  integer.  The 
root  type  of  any  other  type  is  the  type  itself. 

A  variable  can  be  passed  to  a  reference  parameter  only  if  its 
type  is  equivalent  to  the  parameter  type.  An  expression  can  be 
passed  to  a  value  parameter  only  if  it  is  assignable  to  the 
parameter  type. 
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VARIABLE  BINDINGS 


A  variableBinding  is  one  of: 
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COLLECTIONS 


A  collec tionDeclaration  is : 

var  id  H:"  collection  of  typeDefn 

A  collection  is  essentially  an  array  whose  elements  are  dynam¬ 
ically  allocated  and  freed  at  run-time.  Elements  of  a  collection 
are  referenced  by  subscripting  the  collection  name  with  a  vari¬ 
able  of  the  collection's  pointer  type.  This  subscripting  selects 
the  particular  element  of  the  collection  located  by  the  pointer 
variable . 


Elements  of  a  collect 
by  calls  to  the  buil 
allocates  a  new  element 
at  it .  " C. Free ( p) "  fr 

must  be  a  va 
are  invoked 
cannot  be 

in  consta 


eac 

h 

case  p 

ope 

ra 

t 

ions 

men 

ts 

II 

.  The 

Th 

e 

buil 

the 

CO 

llecti 

Co 

i 

lectio 

pa  r 

am 

e 

ter s  o 

"va 

r" 

• 

ion 

are 

allocated 

and 

freed  dynamically 

t-in  operations 

New  and 

Free . 

"C. 

New( 

P)  " 

in 

the 

collecti 

on 

C  and 

se  ts  p 

to 

po 

in  t 

ees 

the 

el ement 

o 

f  C  po 

inted  at 

by 

P- 

In 

r iable 

of  the  po i 

nter  type  of 

C. 

Th 

ese 

as 

statements 

in 

procedures,  s 

ee 

"St  a 

te- 

used  in 

f unc  t io 

ns 

• 

nt 

"C. 

nil"  is 

th 

e  null 

po inter 

va 

1  ue 

for 

s  c 

anno 

t  be  ass 

ig 

ned ,  compa red , 

pa 

ssed 

as 

A 

col 

lection 

m 

ust  b 

e  impo  r 

ted 

us 

i  ng 
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PROCEDURES  AND  FUNCTIONS 


A  proced  ur eDeclarat ion  is : 


procedure  id  ["("  [var]  id 
{"  [var]  id  M 
proced  ur  eBody 


:  parameterType 

pa r amete rType }  ")"] 


n=  ii 


A  function Declaration  is : 

function  id  [ " ( "  id  " : "  parameterType 

{  " , "  id  parameterType}  " )"] 

returns  id  resultType  "=" 

proced  ur eBody 


A  pro 

cedure 

i  s 

invoked  by  a  pro 

ced  ur e 

c 

al 

1  statement,  wi 

th 

ac  tual 

pa  ram e 

ter  s 

i f  r equi red . 

A  funct 

io 

n 

is  invoked  by  usi 

ng 

its  name 

,  wi  th 

ac  t 

ual  parameters  if 

r  equi r 

ed 

r 

in  an  ex 

pr  ession . 

A  pr  o 

ced  ur  e 

may 

return  explicitl 

y  by  ex 

ec 

Ut 

ing  a  re 

turn  stat 

e- 

ment  or 

impl  ic 

itly 

by  reaching  the 

end  of 

th 

e 

proced  ur 

e  body. 

A 

function 

must 

r  etu 

r n  via  " re turn ( ex 

pn)  M. 

Procedures 

and 

functions  may  opt 

ionally 

t 

ake  param 

eters,  the 

types  o 

f  wh ic 

h  ar 

e  defined  in  the 

header . 

Th 

e  parame 

ters  can 

be 

referred 

to  in 

side 

the  procedure  o 

r  f  unc 

ti 

on 

using 

the  nam 

es 

declared 

in 

the 

header.  Parame 

ters  to 

a 

proced  ure 

may  be  d 

e- 

dared  using  " 

var" 

,  which  means  the 

pa  ram e 

te 

r 

may  be  a 

ssig  ned 

to 

or  further  passed  as  a  var  parameter  inside  the  procedure. 
Parameters  declared  without  using  "var"  are  constants  and  cannot 
be  assigned  to  or  passed  as  var  parameters.  Functions  are  not 
allowed  to  have  any  side-effects  and  cannot  have  var  parameters. 
Only  variable  references  can  be  passed  to  var  parameters. 


A  parameter  is  a  reference  parameter  if  it  is  declared  using 
"var"  or  if  its  type  is  an  array  or  record.  Other  parameters  are 
val ue  parameters.  Hence,  a  value  parameter  is  a  non-var  parame¬ 
ter  whose  type  is  a  scalar  or  set. 

A  parameterType  is  one  of: 


a  .  typeDe  fn 

b.  [packed]  a 

typeDe  f n 

c.  universal 

The  type  of  a  var 
parameter  must  be  equ 
following  exceptions 
an  array  parameter  ca 
in  which  case  any  a 
lower  bound  are  equiv 
the  parameter.  (2) 
"universal",  in  which 
the  parameter.  Ins 
equivalent  to  a  param 


rray  mani festConstant  parameter  of 


iable,  record  or  array  passed  to  a  reference 
ivalent  to  the  parameter's  type  with  the 
.  (1)  The  upper  bound  of  the  index  type  of 

n  be  declared  using  the  keyword  "parameter" 
rray  value  whose  element  type  and  index  type 
alent  to  the  parameter's  can  be  passed  to 
The  type  of  a  parameter  can  be  specified  as 
case  a  value  of  any  type  can  be  passed  to 
ide  the  procedure,  a  universal  parameter  is 
eter  of  type  "packed  array  1.. parameter  of 
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StorageUnit"  ,  where  the  upper  bound  is  the  size  of  the  actual 
parameter  in  Storag eUnits .  Parameters  declared  using  "parameter" 
or  "universal"  cannot  be  assigned  or  compared  as  a  whole.  (Note: 
Full  Euclid  does  not  allow  forms  ( b)  and  (c)  .)  Elements  of  packed 
arrays  and  fields  of  packed  records  cannot  be  passed  to  a  refer¬ 
ence  parameter. 

The  type  of  an  expression  passed  to  a  value  parameter  must  be 
assignable  to  the  parameter's  type. 


Euclid-S  does  not 

allow  " al ia 

sing 

"  of  variable 

s  (  i .e  . , 

hav 

ing 

two  names  for  a  given 

variable  or 

par 

t  of  a  given 

variable 

in 

the 

same 

scope) .  Hence 

a  variabl 

e  or 

part  of  a  va 

riable  wh 

ich 

is 

impor 

ted  directly  or 

indirectly  i 

nto 

a  procedure  c 

annot  be 

pas 

sed 

to  a 

reference  par 

ameter  of 

the 

proced  ur e . 

(A  variable 

is 

d  irec 

tly  imported  if 

it  appears  i 

n  the  procedure's 

import 

li 

st . 

It  i 

s  indirectly  i 

mported  if 

an 

imported  module  or  proced 

ure 

d  i  r  ec 

tly  or  indirectl 

y  imports  it 

.) 

Th 

e  returns  clause 

defines  the 

res 

ul t  type  of  a 

function 

• 

The 

retur 

n  identifier  is 

required  for 

com 

pa  t  ib il  i ty  wi 

th  full 

Euc 

lid 

but  c 

annot  be  used  in 

Eucl id-S . 

Th 

e  resultType  of 

a  function  m 

us  t 

be  a  scalar 

type  or 

se  t . 

The 

expression  in  a 

function ' s 

return  statement 

must  be  a 

ssi 

gn- 

able 

to  the  result  type. 

A  proced ureBody  is : 

[imports  "("  [var]  id  [var]  id}  ")  "  ";"] 

beg  in 

[  [not]  checked  "  ;  "] 

[declarationlnRoutine 
{ statement  " ; " } 
end  [  id] 


The  identifier  following  the  "end"  must  be  the  procedure  or 


f unct i 

on  identifier. 

If 

the 

procedure  i 

s  the 

initially 

proced  ure 

of  a  module  then  the 

end 

ide 

nti  f 

ier  must 

not 

be  present 

• 

The 

imports  clause  o 

f  a 

proc 

edure  or 

func 

tion  speci 

fies  those 

global 

identifiers  wh 

ich 

are 

to 

be  visible  in 

side  the 

proced  ure 

or  function.  Only 

those 

var 

iables 

impo  r 

ted  into  a 

proced  ure 

using 

"var"  may  be  assig 

ned 

to  o 

r  passed 

to  a 

var  parameter  in- 

sid  e 

the  procedure. 

Func 

tion 

s  are 

not  a 

11 owed  to  ! 

have  side- 

effects  and  cannot  import  modules,  collections  and  "var"  vari¬ 
ables.  This  restriction  is  transitive;  hence  a  function  cannot 
import  a  procedure  which  imports  anything  "var". 


Procedures  and  functions  may  be  "checked 
statements,  subscripts  and  case  statements 
validity  at  run-time.  In  addition,  a  part 
may  check  other  conditions,  such  as  ranges  i 
cedures  and  functions  not  nested  inside  an 
checked  by  default  and  must  be  explicitly 
checked"  to  turn  off  run-time  checking. 


" ;  this  causes  assert 
to  be  checked  for 
icular  implementation 
n  assignments.  Pro- 
unchecked  module  are 
declared  using  "not 
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A  procedure  returns  when  it  executes  a  return  statement  or 
reaches  the  end  of  the  procedure.  A  function  is  executed  simi¬ 
larly  but  must  return  via  "  return  (  expn)  "  . 

Procedures  and  functions  can  be  separately  compiled;  see 
"Separate  Compilation"  . 

A  declarat ion In Rout ine  is  one  of: 

a.  constantDec lar at  ion 

b.  var iableDeclarat ion 

c.  typeDeclar at ion 

d.  var iableBi nd ing 

e.  collectionDeclaration 

f.  conver terDeclarat ion 

g.  assert  ["("expn")"] 

Modules,  procedures  and  functions  cannot  be  nested  inside  a 
procedure  or  function.  Form  (g)  allows  assert  statements  to 
appear  in  declaration  lists. 


TYPE  CONVERTERS 
A  converter Declaration  is : 

converter  id  "("  typeld  " ) "  returns  typeld 

A  conver terDeclarat ion  declares  a  type  converter.  A  type  con¬ 
verter  is  a  special  function  which  converts  an  expression  to  a 
type  other  than  its  declared  type.  Both  the  parameter  and  result 
type  of  a  type  converter  must  be  named  types.  An  implementation 
is  not  expected  to  generate  any  code  for  a  type  conversion. 


A  type  converter  may  be  used  to  convert  a 
passed  to  a  reference  parameter. 


variable  that  is 


If  the  size  of  the  target  type  is  larger  than  the  size  of  the 
source  type,  the  conversion  may  be  meaningless. 


STATEMENTS 


A  statement  is  one  of: 

a.  variable  M :="  expn 

b.  [module  Id"  .”  ]  procedure  Id  ["("  expn  {","  expn} 

c.  assert  ["("expn")"] 

d.  return  ["("expn")"] 

e.  if  expn  then 

{ statement  " ; " } 

[elseif  expn  then 
{ statement  " ; " } } 

[  el  se 

{ statement  "  ;  " }  ] 
end  i  f 


")  "1 
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eva 

mus 

and 


out 

tor 


f . 

loop 

(statement 

} 

end  loop 

g  • 

exit  [when  expn] 

h. 

case  expn  of 

{ manifestExpn 

IV 

mani festEx pn } 

n  =  n 

{ statement 

" ;  ” ) 

end  manifes 

tEx  pn 

M 

[otherwise  "=> 

fl 

{ statement 

" ; " }  ] 

end  case 

i  . 

beg  in 

{ declarat ionlnRout i 

ne 

" ; " } 

{ statement  "  ;  " 

} 

end 

j  • 

col lec t ionld  " . " 

New  " 

r 

variable  " 

) " 

k . 

collectionld  " ." 

Free 

"  ( 

"  variable 

19  J  II 

Form  (a) 

is  an  assignm 

en  t 

statement . 

The  ex 

pression  is 

luated  and  the  value  assigned 

to 

the  variable.  Th 

e  expression 

t  be  assignable  to  the  va 

r  iabl 

e 

type  (see 

"  Type 

Equival ence 

Assignability”)  . 

Form  (b)  is  a  procedure  call.  An  exported  procedure  is  called 
side  the  module  in  which  it  was  declared  using  the  " opera- 


The  type  of  an  expression  passed  to  a  value  parameter  must  be 
assignable  to  the  parameter's  type.  The  type  of  a  variable  or 
value  passed  to  a  reference  parameter  must  be  equivalent  to  the 
parameter's  type.  If  the  upper  bound  of  the  type  of  an  array 
parameter  is  declared  using  "parameter",  any  array  whose  element 
type  and  index  type  lower  bound  are  the  same  as  the  parameter's 
can  be  passed  to  the  parameter. 


An  actual  parameter  passed  to  a  var 
able,  a  bound  variable  or  a  var  form 
imported  (or  exported)  variable,  it  mus 
exported)  using  "var"  . 


pa  ram 
al  pa 
t  hav 


eter  must  be 
rameter.  If 
e  been  impor 


a  vari- 
it  is  an 
ted  (or 


Form  (c)  is 
is  optional; 
If  present,  it 
evaluated  and 
scope .  Asse  r  t 
declaration  li 


an  assert  statement.  The  par 
if  it  is  omitted,  it  can  be  r 
must  be  of  type  Boolean. 

checked  at  run  time  if  it 
statements  may  appear  in  both 
sts.  They  cannot  appear  insid 


enthesized  expression 
eplaced  by  a  comment. 
The  expression  is 
appears  in  a  checked 
statement  lists  and 
e  records. 


Form  (d)  is  a  return  statement.  The  return  statement 
an  immediate  return  from  the  procedure  or  function  when  ex 
The  optional  parenthesized  expression  gives  the  value  to 
turned  from  a  function.  The  return  expression  is  requi 
function  returns.  It  is  forbidden  for  procedure  retur 
function  must  return  via  a  return  statement  and  not  impl ic 
reaching  the  end  of  the  function  body.  A  procedure  may 
either  via  a  return  statement  or  implicitly  by  reaching 
of  the  procedure  body. 


causes 
ec  uted  . 
be  re- 
red  for 
ns .  A 
itly  by 
return 
the  end 
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Form  (e)  is  an  if  statement.  The  conditional  expression  fol¬ 
lowing  "if"  and  each  "elseif"  is  evaluated  until  one  of  them  is 
found  to  be  true,  in  which  case  the  statements  following  the 
corresponding  "then"  are  executed.  If  none  of  the  expressions 
evaluates  to  true  then  the  statements  following  "else"  are  exe¬ 
cuted;  if  no  "else"  is  present  then  execution  continues  following 
the  if  statement.  The  conditional  expressions  must  be  of  type 
Boolean . 

Form  (f)  is  the  looping  construct  of  Euclid-S.  The  statements 
within  the  loop  are  repeated  until  one  of  its  "exit"  statements 
or  a  "return"  statement  is  executed. 

Form  (g)  is  a  loop  exit.  When  executed,  it  causes  an  immedi¬ 
ate  exit  from  the  nearest  enclosing  loop.  The  optional  "when" 
expression  makes  the  exit  conditional.  If  the  expression,  which 
must  be  Boolean,  evaluates  to  true  then  the  exit  is  executed, 
otherwise  execution  of  the  loop  continues.  An  exit  statement 
cannot  appear  outside  a  loop. 

Form  (h)  is  a  case  statement.  The  case  expression  is  evaluat¬ 
ed  and  compared  with  each  of  the  label  values.  The  statements 
which  follow  the  matching  label  value  are  executed.  If  the  case 
expression  value  does  not  match  any  of  the  label  values  then  the 
statements  following  "otherwise"  are  executed.  If  no  "otherwise" 
is  present,  the  case  expression  must  match  one  of  the  label 
values.  When  execution  of  the  rstatements  following  the  selected 
label  is  completed,  execution  continues  following  the  case  state¬ 
ment  . 


The  type  of  the  case  expression  must  be  Signedlnt  or  Char. 
All  of  the  label  expressions  must  be  of  the  same  type  as  the  case 
expression.  Label  expressions  must  be  manifest,  i.e.,  their 
values  must  be  known  at  compile  time.  The  values  of  all  label 
expressions  in  a  given  case  statement  must  be  distinct.  The 
value  of  the  manifest  expression  following  the  end  of  an  alterna¬ 
tive  must  be  equal  to  the  first  label  expression  of  the  alterna¬ 
tive. 


Form  (i)  is  a  begin  block.  Begin 
local  declarations  within  a  procedure 
lar,  a  they  can  be  used  to  make  local 


blocks  can  be 
or  function, 
b ind  s . 


used 

In 


to  group 
pa  r  t  i  c  u- 


Forms  (j)  and  (k)  are  the  built-in  collection  operations  New 
and  Free  (see  "Collections"). 


VARIABLES  AND  CONSTANTS 


A  variable  is : 

[moduleld  "."]  id  { componentSelector} 

The  syntax  of  variable  includes  variable  and  constant  refer¬ 
ences.  An  exported  variable  or  constant  is  referenced  outside 
the  module  in  which  it  is  declared  using  the  operator. 
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A  component Selector  is  one  of: 


a  . 
b. 


"("  expn  ") 
"  id 


II  \  «• 


Form 

(a) 

allows  subscr 

ipting  of  v 

ar iabl 

e  and 

constant 

ar  r 

ays . 

The 

type  of 

the  subscript 

expression 

must  b 

e  assignable 

to 

the 

ind 

ex 

type 

of  the  array. 

The  value 

of  th 

e  subscript  expres 

sion 

mus 

t  be 

in  the  dec 

lared  range  of  the 

index 

type 

o  f  the 

ar 

ray . 

Sub 

sc  r  i 

pts  which  a 

ppear  in 

checked  sc 

opes  a 

re  checked  for 

val 

idi- 

ty 

at  r 

un- time . 

Form 

(a) 

al  so 

allows 

r e  ferences 

to  elements 

of  a  col] 

Lect 

ion . 

In 

this 

case 

,  the 

subscript  expressio 

n  must 

be  a 

po  in te r 

to 

an 

el ement 

of  the  col 

lection . 

Form 

(b) 

allows 

record 

field  selec 

t  ion . 

Fields  of  a 

record 

var 

iabl 

e  are 

refer 

enced  us 

ing  the  "  ." 

opera 

tor  . 

EXPRESSIONS 


An  expn  is  one  of  the  following: 


a  . 
b . 
c  . 

d . 

e . 

f . 

g. 

h . 

i  . 
j  • 

k . 

l . 
m . 


variable 
literal  Constant 
setTypeld  "("  elementList 
collectionld  " nil 
[moduleld  functionld 

[moduleld  M ."]  converterld 
"  (  "  ex  pn  "  )  " 

"  -  "  ex  pn 

expn  a r i thmet icOpe rator  expn 
expn  compa r isonOperator  expn 
not  expn 

expn  booleanOperator  expn 
expn  setOperator  expn 


II  j  If 

[  "  (  " 
91  ^  19 


ex  pn 
expn 


{" 

") 


expn}  ")"] 


The  ar ithmet icOperators  are  +,  -,  *  (multiply),  div  (integer 
divide)  and  mod  (integer  remainder).  Operands  of  the  arithmetic 
operators  and  unary  minus  must  be  integers  or  expressions  having 
root  type  integer.  The  arithmetic  operators  yield  an  integer 
result.  (Note:  +  and  -  are  also  set  operators;  see  below.) 

The  compar isonOperators  are  <,  >,  =,  <= ,  >=  and  "not  =". 

Operands  of  comparison  operators  must  either  be  the  same  type  or 
have  the  same  root  type;  see  "Type  Equivalence  and  Assignabili¬ 
ty".  The  comparison  operators  yield  a  Boolean  result.  Arrays 
and  records  cannot  be  compared.  Sets  and  Boolean  expressions  can 
be  compared  for  equality  only.  (Note:  <=  and  >=  are  also  set 
operators;  see  below.) 


The  booleanOperator s  are  "and"  (intersection) ,  "or"  (union) 
and  ->  (implication)  .  The  Boolean  operators  and  the  "not"  opera¬ 
tor  take  Boolean  operands  and  yield  a  Boolean  result. 
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The  setOperators  are  *  (set  intersection)  ,  +  (set  union)  , 
(set  difference)  ,  <=  and  >=  (set  inclusion)  ,  and  " in"  and  "not 
in"  (element  containment) .  The  set  operators  +  and  -  take 
operands  of  equivalent  set  types  and  yield  a  set  result.  The  set 
operators  <=  and  >=  take  operands  of  equivalent  set  types  and 
yield  a  Boolean  result.  The  operators  "in"  and  "not  in"  take  a 
set  as  right  operand  and  an  integer  expression  as  left  operand. 
They  yield  a  Boolean  result. 

The  order  of  precedence  is  among  the  following  classes  of 


operators 

(most  binding 

first)  : 

1. 

unary  - 

2. 

*  ,  d  iv  ,  mod 

3. 

+  f  - 

4. 

ii 

V 

II 

A 

v 

V 

>=,  not  =, 

5. 

not 

6. 

and 

7  . 

or 

8. 

-> 

Ex  pr 

ession 

fo 

rm  ( 

a) 

incl ud  es 

references  to 

constants  and 

var  i- 

ables 

includ i 

ng 

el 

ements  of 

arrays  and  co] 

Llections,  fiel 

ds  of 

record  s 

,  and  con 

stan 

ts 

and  variables  exported 

from  a  module. 

Form 

(b) 

includ 

es 

integ  er , 

character  and 

string  literal 

con- 

stants . 

Form 

(c)  is 

a 

set 

constr  uc  tor 

.  The  setTypeld  must  be  the 

name 

of  a  se 

t  type . 

The 

set 

constr  uc 

tor  returns  a 

set  containing 

the 

specified  elements. 

A  setEl ementLi st  is  one  of: 

a  .  [  ex  pn  {  "  , "  ex  pn }  ] 

b.  all 

The  element  list  can  be  a  (possibly  empty)  list  of  expressions 
of  the  base  type  of  the  set,  or  "all".  If  "all"  is  specified, 
the  constructor  returns  the  complete  set.  If  no  elements  are 
specified,  the  constructor  returns  the  empty  set. 

Expression  form  (d)  is  the  null  pointer  value  of  the  specified 
collection. 

Form  (e)  is  a  function  call.  Functions  exported  from  a  module 
are  referenced  outside  the  module  using  the  " ."  operator.  An 
actual  parameter  to  a  function  must  be  an  expression  assignable 
to  the  parameter  type. 

Form  ( f )  is  a  type  conversion.  The  type  of  the  actual  parame¬ 
ter  is  changed  to  the  result  type  of  the  type  converter.  The 
actual  parameter  must  be  an  expression  assignable  to  the  source 
type  of  the  converter.  Type  converters  exported  from  a  module 
are  referenced  outside  the  module  using  the  " ."  operator. 
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BUILT-IN  FUNCTIONS 


Euclid-S  has  two  built-in  functions,  Chr  and  Ord .  "Chr(i)" 
returns  the  character  whose  machine  representation  is  the  posi¬ 
tive  integer  value  i.  "  Cha  r  .Ord  ( c)  "  returns  the  positive  integer 
machine  representation  of  the  character  c.  Chr  and  Ord  are  de¬ 
fined  such  that  for  all  characters  "c"  in  the  machine  character 
set,  Chr ( Char . Ord ( c) )  =  c. 


STANDARD  COMPONENTS 


Euclid-S  d 

e  f  i  n  e 

s  two  standard  com 

ponents,  size 

and 

add  re 

ss . 

"T. 

size"  ret 

urns 

the  length  in  Stor 

ageUnits  (typically 

bytes) 

of 

the 

machine 

repr 

esentation  of 

th 

e  variable 

or 

type 

T. 

"V. 

add  ress" 

re  tur 

ns  the  unsigned 

i 

nteger  machine 

add  re 

ss  o  f 

the 

var 

iable  V. 

(No  te 

:  In  full  Euclid 

» 

"V. address"  is 

1  eg  al 

only 

for 

var 

iables  of 

type 

StorageUnit .) 

SOURCE  INCLUSION  FACILITY 

Other  Euclid-S  source  files  may  be  included  as  part  of  a  pro¬ 
gram  using  the  "include"  statement. 

An  includes tat ement  i s : 

include  str  ing Li  teral  ";" 

The  str ing Li teral  gives  the  name  of  a  Euclid-S  source  file  to 
be  included  in  the  compilation.  The  include  statement  is  re¬ 
placed  in  the  program  source  by  the  contents  of  the  specified 
file. 

Include  statements  can  appear  anywhere  in  a  program  and  can 
contain  any  valid  source  fragment.  Included  source  files  can 
themselves  contain  include  statements. 
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II.  CONCURRENCY  FEATURES  OF  EUCLID-C 


The  Euclid-C  language  is  an  extension  to  Euclid-S  designed  to 
allow  concurrent  programming  with  monitors.  Euclid-S  is  a  subset 
of  Euclid  but  Euclid-C  is  not,  because  concurrency  and  monitors 
are  not  features  of  Euclid. 

The  concurrency  features  of  Euclid-C  will  be  presented  in  the 
following  order: 

(1)  processes,  reentrant  procedures  and  modules; 

(2)  monitors,  entry  procedures  and  functions; 

(3)  conditions,  signalling  and  waiting; 

(4)  simulation,  the  busy  statement. 


PROCESSES 

Each  Euclid-C  module  (including  the  main  module)  can  have  any 
number  of  concurrently  run  processes  associated  with  it. 

A  moduleDeclaration  is : 

var  id  " 
mod  ul e 

(imports  "(M  [var]  id  {","  [var]  id]  " )  ”  " ;  "] 
[exports  "  ("  id  id}  ")  "  ";  "] 

[[not]  checked  ";"] 

[declarationlnModule  M ; " } 

[ initially 

pr oced ur eBody  ";"] 

[process  id  ["("  meinoryRequi  rement  ")"] 
procedureBody  ";"} 
end  module 

Each  process  is  like  a  parameterless  procedure.  Concurrent 
execution  of  the  processes  of  the  module  begins  following  execu¬ 
tion  of  the  initially  procedure  of  the  module.  A  process  ter¬ 
minates  by  executing  its  last  statement  or  by  executing  a  return 
statement.  The  process  identifier  is  for  documentation  only 
since  processes  cannot  be  called. 

Processes  can  communicate  with  each  other  by  changing  and 
inspecting  variables  declared  in  the  module  or  imported  into  it. 
Generally,  however,  processes  communicate  by  means  of  monitors. 

Each  process  requires  a  certain  amount  of  memory  space  for  its 
variables.  When  the  process  calls  a  procedure  or  function,  the 
requirement  increases  to  provide  space  for  the  new  local  vari¬ 
ables.  When  the  procedure  or  function  returns,  the  requirement 
decreases  to  its  former  amount.  The  programmer  can  provide  his 
own  estimate  of  the  process's  required  space  as  a  parenthesized 
manifest  integer  expression  following  the  keyword  "process" . 
This  estimate  is  in  StorageUnits  (normally  bytes)  and  can  be 
based  on  previous  program  executions.  If  this  estimate  is  omit¬ 
ted,  the  implementation  provides  a  default  space  allocation. 
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All  procedures  and  functions  declared  in  a  Euclid-C  program 
are  reentrant,  meaning  that  they  can  be  executed  simultaneously 
by  more  than  one  process. 

Modules,  monitors,  procedures  and  functions  cannot  be  nested 
inside  a  process. 


MONITORS 

A  monitor  is  essentially  a  special  kind  of  module  which  imple¬ 
ments  inter- process  communication  with  synchronization. 

A  declarationlnModule  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBind ing 

e.  modul eDeclarat ion 

f.  moni torDeclarat ion 

g.  collectionDeclarat ion 

h.  procedureDeclarat ion 

i.  f unct ionDeclarat ion 

j.  conver terDeclarat ion 

k.  assert  [M(M  expn  ")"] 

Monitors  may  only  be  declared  inside  modules.  Monitors  cannot 
be  nested  inside  procedures,  functions  or  other  monitors. 

A  moni torDeclarat ion  is : 

var  id  " : " 
monitor 

[imports  "  ( H  [var]  id  [var]  id]  ")  M  "] 

[exports  M("  id  id]  ")  "  M] 

[[not]  checked  ";"] 

{ declarat ionlnMoni tor 
[initially 

pr oced ur eBody  ";"] 
end  monitor 

The  imports  list  of  a  monitor  specifies  the  global  identifiers 
which  are  accessible  inside  the  monitor,  exactly  like  the  imports 
list  in  a  module. 

The  exports  list  of  a  monitor  specifies  those  identifiers 
defined  inside  the  monitor  which  may  be  accessed  outside  the  mon¬ 
itor  using  the  " ."  operator.  Unlike  modules,  monitors  cannot 
export  variables. 

Procedures  and  functions  which  are  exported  from  a  monitor  are 
called  monitor  entr ies .  Entry  procedures  and  functions  of  a  mon¬ 
itor  cannot  be  invoked  inside  the  monitor.  Outside  the  monitor, 
entry  procedures  and  functions  can  be  invoked  exactly  like  the 
procedures  and  functions  of  a  module,  using  the  M."  operator. 
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Procedures  and  functions  which  are  entries  of  a  monitor  cannot 
be  separately  compiled  except  as  part  of  the  entire  monitor. 

It  is  guaranteed  that  only  one  process  at  a  time  will  be  exe¬ 
cuting  inside  a  monitor.  As  a  result,  mutually  exclusive  access 
to  a  monitor's  variables  is  implicitly  provided,  since  a  monitor 
cannot  export  any  variables.  If  a  process  calls  an  entry  of  a 
monitor  while  another  process  is  executing  in  the  monitor,  the 
calling  process  will  be  blocked  and  not  allowed  in  the  monitor 
until  no  other  process  is  executing  in  the  monitor. 

A  declarationlnMonitor  is  one  of  the  following: 

a.  constantDeclar at  ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBind ing 

e.  cond i t ionDeclarat ion 

f.  collectionDeclarat ion 

g.  pr oced ureDeclarat ion 

h.  f unctionDeclarat ion 

i.  conver terDeclarat ion 

j.  assert  ["("  expn  ")"] 

Modules  and  monitors  cannot  be  declared  inside  a  monitor.  A 
monitor  cannot  contain  a  nested  process. 

Monitors  can  be  separately  compiled;  see  "Separate  Compila¬ 
tion"  . 


CONDITIONS 

Euclid-C  introduces  conditions. 

A  cond it ionDeclarat ion  is  one  of: 

a.  var  id  ":"  [priority]  condition 

b.  var  id  ":"  array  indexType  of  [priority]  condition 

The  only  place  a  condition  can  be  declared  is  as  a  field  of  a 
monitor.  The  only  allowed  use  of  conditions  is  in  the  "wait"  and 
"signal"  statements  and  in  the  "empty"  built-in  function.  Condi¬ 
tions  cannot  be  assigned,  compared  or  passed  as  parameters. 
Arrays  of  conditions  are  allowed.  Conditions  must  be  imported 
using  "var"  . 

Two  new  statements  are  introduced: 

wait  "("  conditionVar  [","  pr ior i tyVal ue]  ") " 
signal  "("  conditionVar  ")" 

Wh ere  a  cond i t ionVa r  i s : 

cond it  ion  Id  ["("  expn  ")"] 


20 


The  wait  and  signal  statements  each  specify  a  cond i t ionVa r . 
Each  of  these  must  be  a  conditionld  or  a  subscripted  condition 
array.  These  statements  can  appear  only  in  monitors,  but  not  in 
a  monitor's  initially  procedure. 

When  a  process  executes  a  wait  statement  for  condition  C  it  is 
blocked  and  is  removed  from  the  monitor.  When  a  process  executes 
a  signal  statement  for  condition  C,  one  of  the  processes  (if 
there  are  any)  waiting  for  condition  C  is  unblocked  and  allowed 
immediately  to  continue  executing  the  monitor.  The  signalling 
process  is  temporarily  removed  from  the  monitor  and  is  not  al¬ 
lowed  to  continue  execution  until  no  processes  are  in  the  moni¬ 
tor.  If  no  processes  were  waiting  for  condition  C,  the  only 
effect  of  the  signal  statement  is  that  the  signalling  process  may 
be  removed  from  the  monitor.  The  signalling  process  cannot  in 
general  know  whether  other  processes  have  entered  the  monitor 
before  the  signaller  continues  in  the  monitor. 

If  the  condition  variable  is  declared  with  the  "priority” 
option,  the  wait  statement  must  specify  a  priority  value;  other¬ 
wise  the  priority  value  is  not  allowed  in  wait.  The  priority 
value  is  a  Signedlnt  expression  that  must  evaluate  to  a  nonnega¬ 
tive  integer  value.  The  processes  waiting  for  a  priority  condi¬ 
tion  are  ranked  in  order  of  their  specified  priority  values,  and 
the  process  with  the  smallest  priority  value  is  the  first  to  be 
unblocked  by  a  signal  statement. 

In  the  case  of  processes  waiting  for  non-priority  conditions, 
or  waiting  with  identical  priorities  for  a  priority  condition, 
the  scheduling  is  "fair",  meaning  that  a  particular  waiting  pro¬ 
cess  will  eventually  be  unblocked  given  enough  signals  on  the 
cond it  ion . 

A  predefined  function  named  "empty"  accepts  a  condition  as  a 
parameter.  It  returns  the  Boolean  value  "true"  if  no  processes 
are  waiting  for  the  condition,  otherwise  "false".  Like  wait  and 
signal,  "empty"  can  appear  only  inside  a  monitor,  but  not  in  the 
initially  procedure  of  a  monitor. 

The  variables  in  a  monitor  represent  its  state.  For  example, 
if  a  monitor  allocates  a  single  resource,  only  one  variable  in¬ 
side  the  monitor  is  needed  and  it  can  be  declared  as  Boolean. 
When  this  variable  is  true,  it  represents  the  state  in  which  the 
resource  is  available,  when  false  it  represents  the  state  of 
being  allocated.  When  a  process  enters  the  monitor  and  finds 
that  it  does  not  have  the  desired  state,  the  process  leaves  the 
monitor  and  becomes  blocked  by  executing  a  wait  statement  on  a 
condition.  The  condition  corresponds  to  the  state  that  the  pro¬ 
cess  is  waiting  for.  Suppose  a  process  enters  a  monitor  and 
changes  its  state  to  a  state  that  may  be  waited  for  by  other 
processes.  The  process  should  execute  a  signal  statement  for  the 
condition  corresponding  to  the  new  state.  If  there  are  processes 
waiting  for  this  state  transition,  then  they  will  be  blocked  on 
the  condition,  and  one  of  them  will  immediately  resume  execution 
in  the  monitor.  Because  of  this  immediate  resumption,  the  sig¬ 
nalled  process  knows  the  monitor  is  in  the  desired  state,  without 
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testing  monitor  variables.  The  signalling  process  is  allowed  to 
continue  executing  only  when  no  other  processes  are  in  the  moni¬ 
tor.  If  no  processes  were  waiting  on  the  condition,  the  only 
effect  of  the  signal  statement  is  to  temporarily  remove  the  sig¬ 
naller  from  the  monitor. 

As  specified  by  Hoare,  monitors  and  conditions  are  intended  to 
be  used  in  the  following  manner.  The  programmer  should  associate 
with  the  monitor's  variables  a  consistency  criterion.  The  con¬ 
sistency  criterion  is  a  Boolean  expression  that  should  be  true 
between  monitor  activations,  or  whenever  a  process  enters  or 
leaves  a  monitor.  Hence,  the  programmer  should  see  that  it  is 
made  true  before  each  signal  or  wait  statement  in  the  monitor  and 
before  each  return  from  an  entry  of  the  monitor.  The  programmer 
should  also  associate  a  Boolean  expression,  call  it  Ei ,  with  each 
condition  Ci .  The  expression  Ei  should  be  true  whenever  a  signal 
is  executed  for  condition  Ci  .  A  process  that  is  unblocked  after 
waiting  for  a  condition  knows  that  Ei  is  true  because  the  sig¬ 
nalled  process  (not  the  signalling  process)  executes  first.  (The 
consistency  criterion  and  each  Ei  for  a  condition  do  not  neces¬ 
sarily  appear  as  executable  code  in  the  monitor.)  In  general, 
when  a  process  changes  the  monitor's  state  so  that  one  of  the 
awaited  relations  Ei  becomes  true,  the  corresponding  condition  Ci 
should  be  signalled. 


THE  BUSY  STATEMENT 

A  statement  is  introduced  to  allow  simulation  using  timing 
del  ays : 

busy  " ( "  time  M ) " 

The  "time"  must  be  a  nonnegative  Signedlnt  expression.  The 
busy  statement  can  be  understood  in  terms  of  simulated  time 
recorded  by  a  system  clock.  This  clock  is  set  to  zero  at  the 
beginning  of  execution  of  a  program.  With  the  exception  of  the 
busy  statement  (or  wait  statements  causing  an  indirect  delay  for 
a  busy  statement)  ,  statements  take  negligible  simulated  time  to 
execute.  When  the  programmer  wants  to  specify  that  a  certain 
action  takes  time  to  complete,  the  busy  statement  is  used.  The 
process  that  executes  the  busy  statement  is  delayed  until  the 
system  clock  ticks  (counts  off)  the  specified  number  of  time 
un i ts . 
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III.  SEPARATE  COMPILATION 


This  section  describes  the  extensions  made  to  Euclid-C  to 
allow  separate  compilation  of  procedures,  functions,  modules  and 
monitors . 


EXTERNAL  DECLARATIONS 

Procedures,  functions,  modules  and  monitors  may  be  declared 
"external",  which  means  that  they  are  to  be  separately  compiled 
and  joined  with  the  program  at  link  time. 

An  ex ternalPr oc edure Declaration  i s : 

procedure  id  ["("  [var]  id  pa rameterType 

{","  [var]  id  "  pa  rameterType}  " )  "] 
external 


An  ex ternal Func tionDeclarat ion  i s : 

function  id  ["("  id  pa r amete rType 

id  pa  rameterType}  ")  "] 

returns  id  resultType  "=" 

ex  tnrnal 


An  externalModuleDeclaration  is: 


var  id  " : " 

external  module 

[imports  "("  [var]  id  [var]  id}  " )  "  ";  "] 

[exports  "  ("  id  id}  ")  "  ";"] 

[declarat ionlnEx ternalModule  "} 

end  module 


A  declarat ionlnEx ternal Module  is  one  of: 

a.  constantDeclarat ion 

b.  typeDeclar at  ion 

c.  collectionDeclaration 

d.  externalProcedureDeclarat ion 

e.  externalFunc tionDeclarat ion 


An  ex ternal Monitor Declarat ion  i s : 

var  id  " : " 

external  monitor 

[imports  "("  [var]  id  [var]  id}  ")  "  "] 

[exports  "("  id  id}  ")"  ";"] 

[declarationlnExternalMonitor  " ;  "} 
end  monitor 
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A  declarat ionlnEx ternalMoni tor  is  one  of: 


a.  constantDeclarat ion 

b.  typeDeclarat ion 

c.  collec tionDeclarat ion 

d.  ex ternalProcedureDeclarat ion 

e.  externalFunc tionDeclarat ion 


An  external  declaration  can  appear  in  place  of  the  real  de¬ 
claration  and  specifies  that  the  corresponding  procedure,  func¬ 
tion,  module  or  monitor  is  to  be  compiled  separately. 

Processes  and  initially  procedures  of  modules  cannot  be  de¬ 
clared  external.  Procedures  and  functions  which  are  entries  of  a 
monitor  cannot  be  declared  external  except  as  part  of  an  external 
monitor  declaration.  Constants  declared  within  an  external 
module  or  monitor  must  have  manifest  values. 


COMPILATIONS 

A  compilation  can  consist  of  a  main  program  (see  "Programs") 
or  a  separate  compilation. 

A  sepa  rateCompi 1  at  ion  is : 

{ sepa r ateDeclar at  ion  " ; " } 

Each  sepa rate Declarat ion  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  typeDeclarat ion 

c.  collectionDeclarat ion 

d.  procedureDeclarat ion 

e.  f unc tionDeclarat ion 

f.  moduleDeclaration 

g.  moni torDeclarat ion 

Each  sepa rateDeclarat ion  can  be  a  manifest  constant  declara¬ 
tion,  a  type  declaration,  a  collection  declaration,  a  procedure 
or  function  declared  as  "external"  in  another  compilation,  or  a 
module  or  monitor  declared  as  "external"  in  another  compilation. 

Separately  compiled  procedures,  functions,  modules  and  moni¬ 
tors  can  be  linked  to  form  a  complete  program.  Constants,  types, 
collections  and  variables  are  not  linked  across  compilations;  it 
is  the  programmer's  responsibility  to  insure  that  the  number  and 
type  of  formal  parameters  agree  across  compilations. 
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APPENDIX  1. 

COLLECTED  SYNTAX  OF  EUCLID-S  AND  EUCLID-C 

The  collected  syntax  of  Euclid-S  is  given  first.  Throughout 
the  following,  {item}  means  zero  or  more  of  the  item,  and  [item} 
means  the  item  is  optional. 

The  following  abbreviations  are  used: 
id  for  identifier 
expn  for  expression 
typeDefn  for  typeDef init ion 


A  prog  ram  is : 

moduleDeclarat ion  H;" 


A  moduleDeclarat ion  is : 

v a r  id  "  :  M 
mod  ul e 

[imports  "("  [var]  id  {" ,"  [var]  id}  M)  " 
[exports  "  (  M  id  {  "  ,"  id}  ")  "  H;  "] 

[[not]  checked  H;w] 

{declarationlnModule  " ; " } 

[  initially 

procedureBody  ";"] 
end  module 


A  declarationlnModule  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBi nd ing 

e.  moduleDeclarat ion 

f.  collectionDeclarat ion 

g.  procedureDeclarat ion 

h.  f unc t ionDeclarat ion 

i.  conver terDeclarat ion 

j.  assert  [  "  (  "  expn  ")"] 


A  constantDeclarat ion  is  one  of: 

a.  [pervasive]  const  id  M:=M  expn 

b.  [pervasive]  const  id  typeDefn  ":  =  H 

" ( "  manifestExpn  {","  mani festExpn}  ") " 


A  var iableDeclarat ion  is : 

[register]  var  id  [ " ( "  at  manifestExpn  ")"]  H  : "  typeDefn 

[  "  :  =  H  eXpn] 
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A  type Peel ar a t ion 


is : 


[pervasive]  type  id  typeBody 


The  typeBody  is  one  of: 

a.  typeDefn 

b.  forward 


A  typeDe fn  is  one  of  the  following: 


a.  standardType 

b.  mani festConstant  manifestExpn 

c.  [packed]  array  indexType  of  typePefn 

d.  set  of  baseType 

e.  [packed]  recordType 

f.  pointerType 

g .  namedType 


Note:  The  following  are  standardTypes  of  Euclid-S: 
Signedlnt,  Unsignedlnt,  Longlnt,  Shortlnt,  Boolean,  Char, 
StorageUnit,  AddressType. 


A  recordType  is : 
record 

{ var  id  M:M  typePefn 
end  record 

A  po interType  is : 

" ~ H  collectionld 

A  namedType  is : 

[mod ul eld  ]  type  Id 

A  variableBinding  is  one  of: 

a.  bind  [var]  id  to  variable 

b.  bind  " ( "  [var]  id  to  variable 

{","  [var]  id  to  variable]  ")  " 

A  collectionPeclaration  is : 

var  id  ":M  collection  of  typePefn 
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A  procedur eDeclara t ion  is: 


procedure  id  ["("  [var]  id  "  pa rameterType 

{","  [var]  id  pa  rameterType }  ")  "]  "=" 

procedureBody 

A  £unc tionDeclarat ion  is : 

function  id  [ " ( M  id  pa rameterType 

{  "  , "  id  ":"  pa  rameterType }  " )  M] 
returns  id  ":"  resultType  "  =  " 
pr  oced  ur  eBody 


A  pa  rameterType  is  one  of: 

a.  typeDefn 

b.  [packed]  array  mani festConstant  " parameter  of 

typeDe  fn 

c.  universal 


A  pr oced  ur eBody  is : 

[imports  H  (  -  [var]  id  {  " [var]  id}  ")  "  ";  "] 
beg  in 

[  [ not]  checked  "  ;  M] 

{ declarat ionlnRo ut ine  ";"} 

{ statement  " ;  " } 
end  [ id] 


A  declarationlnRoutine  is  one  of: 

a.  constantDeclarat ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBind ing 

e.  collectionDeclarat ion 

f.  conver terDeclarat ion 

g.  assert  [  "  (  "  expn"  )  "] 


A  conver ter Declaration  is : 

converter  id  "("  typeld  " ) "  returns  typeld 


A  statement  is  one  of: 

a.  variable  "  :  =  "  expn 

b.  [module  Id"  ]  procedur  eld  ["("  expn  {","  expn]  ")  "] 

c.  assert  ["("expn")"] 

d.  return  ["("expn")"] 

e.  if  expn  then 
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{ statement  " ;  " } 

{elseif  expn  then 
{ statement  " ; " } } 

[  el  se 

{ statement  " ; " } ] 
end  i  f 

f.  loop 

{ statement  "  ;  M  } 
end  loop 

g.  exit  [when  expn] 

h.  case  expn  of 

{ manifestExpn  mani festExpn]  "=>" 

{ statement  M ; " } 
end  manifestExpn 
[otherwise  "  =  >" 

{ statement  " ; " }  ] 
end  case 

i .  beg  in 

{  declarationlnRout ine  ";"} 

{ statement  " ; "  } 

end 

j.  collectionld  "."  New  " ( "  variable  ")" 

k.  collectionld  " Free  "("  variable  ")" 


A  variable  is : 

a .  mod ul eld  "  . "  id 

b.  id  { componentSel ec tor } 


A  componentSel ec  tor  is  one  of: 

a  .  "  (  "  expn  "  )  " 

b.  "."id 


An  ex pn  is  one  of  the  following: 


a  . 
b . 
c  . 
d  . 

e . 

f . 

9  • 
h . 
i  . 
j  • 

k . 
1  . 
m . 


variable 
literal Constant 
setTypeld  "("  elementList  ")" 
collectionld  nil 

[module  Id  "."]  function  Id  ["("  expn  expn}  ")  "] 

[moduleld  "."]  converterld  "("  expn  ")" 

"("  expn  ")" 

"  -  "  ex  pn 

expn  a r i thmet icOpe rato r  expn 
expn  compar isonOperator  expn 
not  expn 

expn  booleanOpe rator  expn 
expn  setOperator  expn 


Note:  The  ar ithmeticOperators  are  + ,  *  (multiply)  ,  d iv  (in¬ 
teger  divide)  and  mod  (integer  remainder).  The 
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compar isonOperator s  are  <,  >f  =  ,  <=,  >=  and  "not  =".  The 

booleanOperator s  are  "and"  (intersection)  ,  "or"  (union)  and  -> 
(implication) .  The  setOperators  are  *  (set  intersection) ,  +  (set 
union)  ,  -  (set  difference)  ,  <=  and  >=  (set  inclusion)  ,  and  "in" 

and  "not  in"  (element  containment). 

The  order  of  precedence  is  among  the  following  classes  of  opera¬ 
tors  (most  binding  first): 

1.  unary  - 

2 .  *  ,  d  iv  ,  mod 

3  .  + ,  - 

4.  <,  >,  = ,  <=,  >= ,  not  =,  in,  not  in 

5 .  not 

6 .  and 

7 .  or 

8.  -> 


A  setElementLi st  is  one  of: 

a  .  [  expn  {  "  expn}  ] 

b.  all 


An  includeStatement  is : 

include  str ing Li teral 

Note:  Include  statements  can  appear  anywhere  in  a  program. 
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The  following  changes  and  additions  are  made  to  form  Euclid-C 


A  moduleDeclarat ion  is: 


var  id  " 
modul  e 

[imports  "  ( M  [var]  id  {  "  [var]  id]  ")  -  ";  "] 
[exports  "("  id  id}  ")  M  ";"] 

[  [not]  checked  "  ;  "] 

{ declarat ionlnMod ule 
[  initially 

procedureBody  ";"] 

{process  id  ["("  memoryRequi rement  ")"] 
procedureBody 
end  module 


A  declarat ionlnMod ule  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBi nd ing 

e.  modul eDeclarat ion 

f.  moni torDeclarat ion 

g.  collectionDeclarat ion 

h.  procedureDeclarat ion 

i.  f unc t ionDec lara t ion 

j.  conver terDeclarat ion 

k.  assert  ["("  expn  ")"] 


A  monitorDeclaration  is : 

var  id  "  :" 
monitor 

[imports  "("  [var]  id  [var]  id]  " )  "  " ;"] 

[exports  "  ("  id  id}  ")  "  "] 

[[not]  checked  ";"] 

{ declarat ionlnMonitor  ";"} 

[ initially 

procedureBody  ";"] 
end  monitor 


A  declarationln Moni tor  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  var iableDeclarat ion 

c.  typeDeclarat ion 

d.  var iableBi nd ing 

e.  cond i t ionDec 1 ar a t ion 

f.  col 1 ec t ionDec lara t ion 

g.  procedureDeclarat ion 

h.  f unc tionDeclarat ion 
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i.  converterDeclarat ion 

j.  assert  [  "  (  "  expn  ")"] 


A  cond it ionDeclarat ion  is  one  of: 

a.  var  id  " [priority]  condition 

b.  var  id  array  indexType  of  [priority]  condition 


A  statement  is  one  of: 

a.  variable  expn 

b.  [  mod  ul  eld  "  . H  ]  procedure  Id  [  "  (  "  expn  [  "  , "  expn}")"] 

c.  assert  ["("expn")"] 

d.  return  ["("expn")"] 

e.  if  expn  then 

[  statement  " ;  "  } 

[elseif  expn  then 
{  statement  " ; "  } } 

[  el  se 

{ statement  " ; " } ] 
end  i  f 

f.  loop 

{ statement  "  ;  "  } 
end  loop 

g.  exit  [when  expn] 

h.  case  expn  of 

{ mani f estExpn  [","  mani festExpn]  "=>" 

{ statement  " ; " } } 

[otherwise  "=>" 

[statement  " ; " } ] 
end  case 

i .  beg  in 

{ declarat ionlnRout ine  ";"} 

[statement  " ; " } 

end 

j.  col lection Id  New  " ( "  variable  ")" 

k.  collectionld  Free  "("  variable  ")" 

l.  wait  "("  conditionVar  [","  pr ior i tyVal ue]  ") " 

m.  signal  "("  conditionVar  ")" 

n .  busy  " ( "  time  " ) " 


A  cond i t ionVa r  i s : 

conditionld  ["("  expn  ")"] 
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The  following  extensions  allow  separate  compilation  of  pro¬ 
cedures,  functions,  modules  and  monitors: 


An  ex te rnal Pr oc edure Declaration  i s : 

procedure  id  ["("  [var]  id  " pa rameterType 

{","  [var]  id  pa r amete rType }  " )"]  "=" 

external 


An  ex ternalFunctionDeclarat ion  i s : 

function  id  [ " ( "  id  pa rameterType 

{",M  id  pa rameterType }  ") "] 

returns  id  M:"  resultType  "  =  M 
ex  te  rnal 


An  ex ternalMod ul eDeclarat ion  is: 


var  id  " 

external  module 

[imports  "  ( "  [var]  id  [var]  id}  ")  " 

[exports  "("  id  id}  ")  "  "] 

{ dec lara t ionln Ex ternal Mod ul e  " ; " } 
end  module 


A  declarat ionlnEx ternalModule  is  one  of: 


a.  constantDecl arat ion 

b.  typeDeclara t ion 

c.  collectionDeclaration 

d.  ex ternalProcedureDeclarat ion 

e.  externalFunctionDeclaration 


An  ex ternal Monitor Declarat ion  i s : 

var  id  " : " 

external  monitor 

[imports  "  ( "  [var]  id  [var]  id}  ")  "  "] 

[exports  "  ("  id  {  " ,"  id}  ")"  "] 

[declarationlnEx ternalMoni tor  " ; "} 
end  monitor 


A  declarationlnEx ternalMoni tor  is  one  of: 

a.  constantDeclarat ion 

b.  typeDecl arat  ion 

c.  collectionDeclaration 

d.  ex ternal Proced ureDec lara t ion 

e.  externalFunctionDeclaration 
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Note:  An  external  declaration  can  appear  in  place  of  the 
declaration  anywhere  in  a  program. 


A  separateCompilation  is : 

{ sepa r ateDeclarat ion 


Each  sepa r ateDeclarat ion  is  one  of  the  following: 

a.  constantDeclarat ion 

b.  typeDeclarat ion 

c.  col lec tionDeclarat ion 

d.  procedureDeclarat ion 

e.  func tionDeclarat ion 

f.  moduleDeclarat ion 

g.  moni torDeclarat ion 


real 
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APPENDIX  2. 

KEYWORDS  AND  PREDEFINED  IDENTIFIERS  OF  EUCLID-S  AND  EUCLID-C 

The  following  are  reserved  words  of  Euclid.  These  must  not  be 
used  as  identifiers  in  Euclid-S  and  Euclid-C  programs.  Those 
which  are  not  in  the  Euclid-S  subset  are  marked  with  an  *. 


♦abstraction 

*al  igned 

all 

and 

♦any 

a  r  ray 

assert 

at 

beg  in 

bind 

*  bits 

*  bound 

case 

♦checkable 

checked 

♦code 

collec  tion 

const 

converter 

♦counted 

♦decreasing 

♦defaul  t 

♦depend  ent 

div 

el  se 

el se i f 

end 

exit 

exports 

♦finally 

*  for 

fo  rwa rd 

♦from 

f unc  t ion 

if 

impor  ts 

in 

include 

initially 

*  ini ine 

♦invariant 

loop 

mach i ne 

mod 

not 

o  f 

or 

o  the  rwi se 

pac  ked 

parameter 

pervasive 

♦post 

*pr  e 

procedure 

*  readonly 

record 

return 

returns 

set 

then 

♦  thus 

to 

type 

*  un  known 

var 

when 

♦wi  th 

*  xor 

The  following 

are  additional 

reserved  words 

of  Euclid-S  and 

Euclid-C.  These 

also  must  not 

be  used  as  identifiers  in  Euclid-S 

and  Euclid-C  programs. 

busy 

cond it  ion 

empty 

mon i tor 

pr  ior ity 
wait 

process 

r eg  ister 

sig  nal 

The  following 

are  predefined 

identifiers  of 

Euc lid.  In  g  en- 

eral  ,  these  are  pervasive  and  must  not  be  redeclared  in  Euclid 

programs.  Those 
wi th  an  *  . 

which  are  not 

in  the  Euclid-S 

subset  are  marked 

*  Abs 

add  ress 

Add  ressType 

*  al ig  nment 

*  BaseType 

Boolean 

Char 

Chr 

*  Component Type 

false 

♦first 

Free 

♦index 

♦indexType 

♦In  teg  er 

* i tsTag 

*1 tsType 

*  last 

♦Max 

♦Mi  n 

New 

nil 

♦Ob j  ec  tType 

♦Odd 

Ord 

*Pr  ed 

♦ref  Co  unt 

Signed Int 

size 

♦size InBi ts 

Storag  eUn i t 

♦St r ing 

♦String Ind  ex 

♦  s  t  r  i  ng  Ma  x  Le  ng  th 

♦Succ 

♦SystemZone 

true 

Unsigned Int 

The  following  are  additional  predefined 

identifiers  of 

Euclid-S  and  Euclid-C.  These  also  must  no 

t  be  redeclared  in 

Euclid-S  and  Euc 

lid-C  programs. 

Long  In t 

Sho  r  t In  t 
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APPENDIX  3. 

INPUT/OUTPUT  IN  CONCURRENT  EUCLID 

This  paper  presents  the  standard  input/output  package  for 
Euclid-S  and  Euclid-C.  The  user  can  access  the  I/O  facility  by 
including  in  his  program  the  stub  input/output  module  which 
corresponds  to  the  level  of  I/O  which  his  program  requires.  In 
this  way,  the  user's  compiled  and  linked  program  will  include 
code  only  for  the  I/O  facilities  required. 

The  package  provides  four  levels  of  sophistication,  which  are 
called  "10/1"  through  "10/4".  Each  level  includes  all  the  facil¬ 
ities  of  the  previous  levels  plus  certain  new  features.  The  lev¬ 
els  are  as  follows: 

10/1 :  Terminal  (standard)  input  and  output;  Formatted  text 

input/output  of  integers,  characters  and  strings  (Get  and 
Put)  . 

IQ/2 :  Program  argument  sequential  files;  Open  and  close  on  argu¬ 

ment  files;  Formatted  text  input/output  of  integers,  charac¬ 
ters  and  strings  to  files  (FGet  and  FPut) ;  Internal 
representation  input/output  of  integers,  characters  and 
strings  to  files  (Read  and  Write);  End  of  file  detection 
(End  Fi 1 e)  . 

10/3 :  Temporary  and  non-argument  sequential  files  (Assign,  Deas¬ 

sign,  Delete);  Program  arguments  (FetchArg)  . 

I_0/4_:  Record,  array  and  storage  input/output  (Read  and  Write); 
Random  access  files  (Stat  and  Seek);  Error  detection 
(Error) . 

The  procedures  and  functions  of  the  input/output  system  are 
all  part  of  the  module  "10"  and  must  be  referenced  using  "10.". 
The  types  and  constants  which  form  the  interface  to  the  module 
are  global.  The  user  can  access  the  level  n  facilities  of  the 
input/output  module  by  beginning  his  program  with  the  statement 

include  'IOn' 

We  now  describe  the  input/output  facilities  in  detail. 


_I0/1_:  Te rm inal  Fo rmatted  Tex t  I/O 

pervasive  const  newLine  :=  $$N 
pervasive  const  endOfFile  :=  $$E 
pervasive  const  maxSt r ing Leng th  := 

{  Implementation  defined;  >=  128  } 

Strings  read  and  written  by  the  input/output  routines  may  be 
up  to  maxSt  r  ing  Leng  th  characters  in  length. 

IO.PutChar  (c:  Char) 

Prints  the  character  c  on  the  terminal. 
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IO.Putlnt  (i:  Signedlnt,  w:  Signedlnt) 

Prints  the  integer  i  on  the  terminal,  right  justified  in  a 
field  of  w  characters.  Leading  blanks  are  supplied  to  fill 
the  field.  If  w  is  an  insufficient  width,  the  value  is 
printed  in  the  minimum  possible  width  with  no  leading 
blanks.  In  particular,  if  w  is  1  then  the  exact  number  of 
characters  needed  is  used.  The  specified  width  must  be 
greater  than  zero  and  less  than  maxSt r ing Leng th . 

IO.PutString  (s:  packed  array  1. .parameter  of  Char) 

Prints  the  string  s  on  the  terminal.  The  string  must  be 
terminated  by  an  endOfFile  character  ('$E*),  which  is  not 
output.  It  can  contain  embedded  newLines  ('$N')  if  desired. 
(Note:  An  endOfFile  character  ($$E)  can  be  output  using 
PutCha  r . ) 

IO.GetChar  (var  c:Char) 

Gets  a  the  next  input  character  from  the  terminal.  End  of 
file  is  indicated  by  a  return  of  endOfFile  ($$E). 

IO.Getlnt  (var  i:  Signedlnt) 

Gets  an  integer  from  the  terminal.  The  input  must  consist 
of  any  number  of  optional  blanks,  tabs  and  newlines,  fol¬ 
lowed  by  an  optional  minus  sign,  followed  by  any  number  of 
decimal  digits. 

IO.GetString  (var  s:  packed  array  1.. parameter  of  Char) 

Gets  a  line  of  character  input  from  the  terminal.  The 
string  returned  is  ended  with  the  newLine  character  ('$N') 
followed  by  an  endOfFile  character  (  *  $  E  * )  .  The  returned 
string  may  be  up  to  maxStr ing Leng th  characters  in  length. 
End  of  file  is  indicated  by  returning  a  string  containing 
endOfFile  ('$E')  as  the  first  character. 


^0/2^:  Sequential  Arg  umen  t  File  I/O 

pervasive  const  stdlnput  :=  -2 
pervasive  const  stdOutput  :=  -1 
pervasive  const  stdError  :=  0 

pervasive  const  rnaxArgs  :  =  {  Implementation  defined;  >=  9  } 
pervasive  const  maxFiles  := 

{  Implementation  defined;  >=  maxArgs+5  } 
type  File  =  stdError . .maxFiles 

Concurrent  Euclid  input/output  refers  to  files  using  a  file 
number.  Certain  file  numbers  are  preassigned  as  follows:  -2 
refers  to  the  terminal  input;  -1  is  the  terminal  output;  0 
is  the  standard  diagnostic  output.  The  file  numbers 
l..maxArgs  refer  to  the  program  arguments.  The  remaining 
file  numbers  ( maxArg s+1 . .max Fi 1 es)  can  be  dynamically  as¬ 
signed  to  files  using  the  " 10. Ass ig n"  operation;  see  "10/3". 

pervasive  const  inFile  :=  0 
pervasive  const  outFile  :=  1 
pervasive  const  inOutFile  :=  2 
type  FileMode  =  inFi 1 e . . i nOut Fi 1 e 
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Files  can  be  opened  for  input,  output,  or  input/output  using 
modes  inFile,  outFile  and  inOutFile  respectively.  (Note: 
The  input/output  mode  is  not  available  under  Unix  V6.) 

10. Open  (f:  File,  in:  FileMode) 

10. Close  (f:  File) 

With  the  exception  of  terminal  input/output  and  the  standard 
diagnostic  output,  files  must  be  opened  before  they  are  used 
and  closed  before  the  program  returns.  Open  opens  an  exist¬ 
ing  file  for  the  operations  specified  by  the  mode.  If  the 
opened  file  does  not  exist,  it  is  created.  The  file  number 
specified  must  be  a  preassigned  file  number  or  a  file  number 
returned  from  a  call  to  "10. Assign";  see  "10/3". 

IO.FPutChar  (f:  File,  c:  Char) 

IO.FPutlnt  (f:  File,  i:  Signedlnt,  w:  Signedlnt) 

10. FPutStr ing  (f:  File,  s:  packed  array  1. .parameter  of  Char) 

IO.FGetChar  (f:  File,  var  c:  Char) 

IO.FGetlnt  (f:  File,  var  i:  Signedlnt) 

10. FGetStr ing  (f:  File,  var  s:  packed  array  1. .parameter  of  Char) 
These  operations  are  identical  to  the  terminal  input/output 
operations  of  10/1  except  that  the  put  or  get  is  done  on  the 
specified  file. 

10. Write Char  (f:  File,  c:  Char) 

Identical  to  FPutChar. 

IO.Writelnt  (f:  File,  i:  Signedlnt) 

Writes  the  internal  representation  of  integer  i  to  the 
specified  file. 

IO.Wr i teStr ing  (f:File,  s:  packed  array  1. .parameter  of  Char) 
Identical  to  FPutString. 

IO.ReadChar  (f:  File,  var  c:  Char) 

Identical  to  FGetChar. 

IO.Readlnt  (f:  File,  var  i:  Signedlnt) 

Reads  an  integer  in  internal  representation  from  the  speci¬ 
fied  file  into  i . 

10. ReadStr ing  (f:  File,  var  s:  packed  array  1. .parameter  of  Char) 
Identical  to  FPutString. 

10 . End  Fi 1 e  (f:  File) 

A  function  which  returns  true  if  the  last  operation  on  the 
specified  input  file  encountered  end  of  file  and  false  oth¬ 
erwise. 
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I_0/3_:  Temporary  and  Non- arg  ument  Files 


pervasive  const  maxArgLength  :  = 

{  Implementation  defined;  >=  32  } 

File  names  and  arguments  to  a  program  may  be  up  to  maxAr¬ 
gLength  characters  in  length. 

10. Assign  (var  f:  File,  s:  packed  array  1. .parameter  of  Char) 

A  file  number  is  assigned  to  the  file  name  supplied  in  s. 
The  file  name  is  given  as  a  string  terminated  by  the  endOf- 
File  character  ('$E'),  which  is  not  part  of  the  name.  Be¬ 
fore  the  file  can  be  used  it  must  be  opened  using  "10. Open" . 

10. Deassign  (f:  File) 

The  specified  file  number  is  freed  for  assignment  to  another 
file  name.  An  open  file  cannot  be  deassigned. 

10. Delete  (f:  File) 

The  specified  file  is  destroyed.  An  open  file  cannot  be 
deleted.  Note  that  a  program  can  have  temporary  files  using 
"10. Assign"  and  "10. Delete". 

IO.FetchArg  (n:  l..maxArgs,  var  s:  packed  array  1. .parameter  of 
Char) 

The  program  argument  specified  by  " n"  is  returned  in  string 
s.  The  returned  string  is  terminated  by  the  endOfFile  char¬ 
acter  ( *  $ E  * )  and  may  be  up  to  maxArgLength  characters  in 
leng  th . 


K)/£:  Str uc ture  Input/Output  and  Random  Access  Files 

10. Write  (f:  File,  u:  universal,  n:  Signedlnt) 

The  number  of  StorageUnits  specified  by  " n"  are  written  to 
the  file  from  u.  Write  can  be  used  to  write  out  whole  ar¬ 
rays  and  records  using  a  call  of  the  form  "10. Write  (f,  v, 
v.size) ",  The  value  of  n  must  be  positive  or  zero. 

10. Read  (f:  File,  var  u:  universal,  n:  Signedlnt) 

The  number  of  StorageUnits  specified  by  " n"  are  read  from 
the  file  into  u.  Read  can  be  used  to  read  in  whole  arrays 
and  records  using  a  call  of  the  form  "10. Read  (f,  v, 
v.size)".  The  value  of  n  must  be  positive  or  zero. 

type  File Index  = 
record 

var  b:  Signedlnt 
var  c:  Signedlnt 
end  record 

IO.Stat  (f:  File,  var  x:  Filelndex) 

10. Seek  (f:  File,  x:  Filelndex) 

These  operations  provide  random  access  input/output  by  al¬ 
lowing  the  program  to  sense  a  file  position,  represented  as 
two  integers,  and  reset  the  file  to  a  remembered  position. 
Stat  returns  the  current  position  of  the  specified  file  in 
x.b  and  x.c  (conceptually,  the  "block  number"  and  "character 
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number  within  block")  .  Seek  sets  the  current  position  of 
the  specified  file  to  the  position  specified  by  the  values 
of  x.b  and  x.c.  In  both  cases,  the  values  of  b  and  c  are 
integers  whose  meaning  is  implementation-dependent.  The 
programmer  should  not  assume  that  the  values  of  b  and  c  are 
restricted  to  any  particular  range.  (Note:  "IO.Stat"  and 
"10. Seek"  are  not  supported  under  Unix  V6.) 

10. Error  ( f :  File) 

A  function  which  returns  true  if  the  last  operation  on  the 
specified  file  encountered  an  error  and  false  otherwise. 


Interfacing  to  Unix* 

The  input/output  package  is  based  on  standard  Unix 
input/output  and  is  designed  to  be  interfaced  to  Unix  with  a 
minimum  of  overhead.  The  Unix  implementation  is  written  in  C  and 
uses  only  facilities  of  the  C  "stdio"  package.  This  implementa¬ 
tion  can  be  compiled  unchanged  under  both  V6  and  V7  Unix. 


Using  Eucl  id-S  Standard  I_/0  wi  th  Toronto  Euclid 

Euclid-S  programs  may  be  compiled  using  Toronto  Euclid  by 
wrapping  the  entire  Euclid-S  program  (including  all  "include" 
statements)  in  a  module  type,  thus: 

type  Eucl  idS  =  module 

include  ' I  On  ' 

{  The  Euclid-S  program  goes  here  } 
end  module  {EuclidS}; 

The  program  can  then  be  compiled  using  the  command  "euc  -E 
prog.e".  The  "-E"  option  specifies  that  the  program  is  to  be 
linked  with  the  Euclid-S  standard  I/O  library. 

The  Euclid-S  input/output  facility  has  been  installed  in  the 
Toronto  Euclid  library  and  can  be  referenced  directly  using 

include  ' /I ib/eucl id/IOn ' 

if  desired.  In  this  way,  the  user  need  not  have  his  own  copies 
or  links  to  the  input/output  package. 


*  "Unix"  is  a  trademark  of  Bell  Telephone  Laboratories. 
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